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(57) 



ABSTRACT 



A method and apparatus for interfacing buses includes a 
system interface processor coupled to a first bus and includ- 
ing a command register accessible via a second bus. A 
request buffer and a response buffer are provided which are 
accessible via the second bus and coupled to the interface 
processor. The request buffer can be used to store informa- 
tion to be transmitted from the second bus to the first via the 
interface processor while the response buffer can be used to 
store information to be transmitted from the first bus to the 
second bus via the interface processor. The interface pro- 
cessor may include a status register to indicate the status of 
the interface controller. The interface controller may also 
include a command register to receive commands transmit- 
ted over the second bus. 

16 Claims, 13 Drawing Sheets 
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COPYRIGHT RIGHTS 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent files or records, but otherwise reserves all copyright 
rights whatsoever. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to interfaces between communica- 
tion buses in electronic systems. Additionally, the invention 
relates to an interface between two buses in a computer 
system. 

2. Description of the Related Technology 

In the electronics industry, and more particularly in the 
computer industry, various bus architectures are used to 
permit parts of computer systems, multiple processors, and 
controllers to communicate. However, different bus archi- 
tectures which are governed by different standards are 
frequently used within a single overall system. Therefore, 
there is a continuing need to develop interface methods and 
systems to permit communication between different buses. 

One such bus architecture is the Inter-IC control bus (I 2 C 
bus). The FC bus is a bi-directional two- wire bus (a serial 
data line and a serial clock line). Advantages of the I 2 C bus 
architecture are that it provides flexibility and lowers inter- 
connecting costs by reducing board space and pin count. The 
I 2 C bus has particular application in video cards for com- 
puter systems and electronic components such as television 
tuners, AM/FM tuners, video decoders, video encoders, 
television audio decoders and video cross bars). 

Another common bus architecture is the Industry Stan- 
dard Architecture (ISA bus). The ISA bus is commonly used 
in computer systems to transfer data to and from the central 
processing unit or units. 

There is a need for a method and apparatus for interfacing 
an I 2 C with an ISA bus. Such an interface would permit a 
CPU in a computer system to communicate with devices 
interconnected over an I 2 C bus. 

SUMMARY OF THE INVENTION 

The invention addresses the above and other needs by 
providing an interface apparatus and method, which in one 
embodiment includes a system interface processor coupled 
to a first bus and including a command register accessible 
via a second bus. A request buffer and a response buffer are 
provided which are accessible via the second bus and 



25 



30 



35 



40 



45 



55 



60 



65 



coupled to the interface processor. The request buffer can be 
used to store information to be transmitted from the second 
bus to the first via the interface processor while the response 
buffer can be used to store information to be transmitted 
from the first bus to the second bus via the interface 
processor. The interface processor may include a status 
register to indicate the status of the interface controller. The 
interface controller may also include a command register to 
receive commands transmitted over the second bus. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a computer system employ- 
ing an embodiment of the invention; 

FIG. 2 is a system block diagram of one embodiment of 
a system interface in accordance with the invention; 

FIG. 3 is a circuit diagram of an embodiment of the 
system interface depicted in FIG. 2; 

FIGS. 4A and 4B are flow charts depicting the process 
followed in one embodiment of the invention in connection 
with transmitting a message through the system interface; 

FIGS. SAand SB are flow charts depicting the process for 
one embodiment of the invention wherein a client monitors 
the system interface for events; 

FIGS. 6Aand 6B are flow charts depicting the process for 
one embodiment of the invention wherein the system inter- 
face responds to requests from devices on the two buses; and 

FIGS. 7 A, 7B and 7C are flowcharts depicting the process 
carried out by a driver for communicating across the inter- 
face. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The invention will be described in terms of exemplary 
embodiments adapted to operate with particular computer 
systems. However, it will be clear to those skilled in the art 
that the principles of the invention can be utilized in other 
computer systems where it is desired to provide an interface 
between buses. The exemplary embodiments are described 
below in further detail with reference to the Figures, wherein 
like elements are referenced by like numerals throughout. 

One specific environment in which the invention can be 
utilized is described in application Ser. No. 08/942,402 
entitled "Diagnostic and Managing Distributed Processor 
System" and application Ser. No. 08/942,168, entitled 
"Method for Automatically Reporting a System Failure in a 
Server", which are incorporated herein by reference above 
and is described below in general terms in order to provide 
the reader with an example of a specific application of the 
invention. However, the invention can be utilized in various 
other systems. 

Referring to FIG. 1, a block diagram of an embodiment of 
a server system 100 is illustrated. The server system 100 
may include a central processing unit (CPU) 101 which 
executes the operating system (OS) software which controls 
the communications protocol of the server system 100. The 
CPU 101 is coupled to an Industry Standard Architecture 
bus (ISA bus) 103 which transfers data to and from the CPU 
101. The ISA bus 103 and its functionality are well-known 
in the art Coupled to the ISA bus 103 is a system interface 
105 which provides an interface between the ISA bus and an 
I^C bus 107. The interface 105 acts as an interface between 
the ISA bus and an I 2 C bus which couples a group of 
microcontrollers that monitor and control various sub- 
systems and components of the server system 100. As 
described in further detail below, a message such as an event 
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message sent to the system interface 105 may indicate that 
a system failure or error has occurred. Additionally, other 
information including date, queries and commands may be 
sent across the system interface 105. As used herein, the 
term "event" may refer to the occurrence of any type of 
system failure or warning. The structure and functionality of 
the system interface 105 is described in greater detail below 
with respect to FIG. 2. 

Coupled to the system interface 105 is a system bus 107. 
In one embodiment, the system bus 111 is an Inter-IC control 
bus (f*C bus), which transfers data to and from the various 
controllers and subsystems mentioned above. The 
command, diagnostic, monitoring, and logging functions of 
the failure reporting system of the invention may be 
accessed through the common I 2 C bus protocol. The t*C bus 
protocol uses a slave address as the means of identifying the 
devices on the bus. Any function can be queried by gener- 
ating a "read" request, which has its address as part of its 
protocol format. Conversely, a function can be executed by 
"writing" to an address specified in the protocol format. Any 
controller or processor connected to the bus can initiate read 
and write requests by sending a message on the I 2 C bus to 
the processor responsible for that function. 

Coupled to the system bus 107 is a CPU A controller 109, 
a CPU B controller 111, a chassis controller 112 and four 
canister controllers 113. These controllers monitor and con- 
trol various operating parameters and/or conditions of the 
subsystems and components of the server system 100. For 
example, CPU A controller 109 may monitor the system fan 
speeds, CPU B controller 111 may monitor the operating 
temperature of the CPU 101, the chassis controller 112 may 
monitor the presence of various circuit boards and compo- 
nents of the server system, and each of the canister control- 
lers 112 may monitor the presence and other operating 
conditions of "canisters" connected to the server system 
100. A "canister" is a detachable module which provides the 
ability to expand the number of peripheral component 
interface (PCI) devices that may be integrated into the server 
system 100. Each canister is capable of providing I/O slots 
for up to four PCI cards, each capable of controlling and 
arbitrating access to a PCI device, such as a CD ROM disk 
drive, for example. If one or more of the various controllers 
detects a failure, the respective controller sends an event 
message to the system interface 105 which subsequently 
reports the occurrence of the event to the CPU 101. In one 
embodiment, the controllers 109, 111 and 113 are PIC16C65 
microcontroller chips manufactured by Microchip 
Technologies, Inc. and the chassis controller 112 is a 
PIC16C74 microcontroller chip manufactured by Microchip 
Technologies, Inc. 

Upon detecting a failure condition, a controller (109, 111, 
112 or 113) not only transmits an event message to the 
system interface 105, but also transmits failure information 
associated with the failure condition to a system recorder 
115 connected to the system bus 107. The system recorder 
115 then assigns a time stamp to the failure information and 
logs the failure by storing the failure information, along with 
its time stamp, into a system log 117. The operation and 
functionality of the system recorder 115 is described in 
further detail below with reference to FIG. 6. In one 
embodiment, the system log 117 is a non-volatile random 
access memory (NVRAM), which is well-known for its 
characteristics in maintaining the integrity of data stored 
within it, even when power to the memory cells is cut off for 
extended periods of time as a result of a system shutdown or 
power failure. The following are examples of various moni- 
toring functions performed by some of the controllers 
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described above. However, it is understood that the inven- 
tion is not limited to these monitoring functions which serve 
only as examples. 

For example, the controller 109 may be coupled to a 
system fan unit (not shown) and periodically monitor the 
speed of the fan. In one embodiment, the fan unit transmits 
a pulse wave form to the controller 109, the frequency of 
which is proportional to the rate of rotation of the fan. The 
controller 107 checks the frequency of the pulse wave form 
on a periodic basis and determines whether the frequency is 
within a specified range of acceptable fan speeds. If a 
measured frequency is too slow, the controller 109 detects a 
fan failure condition and sends an event message to the 
system interface 105. The controller 109 also sends failure 
information to the system recorder 115 which assigns a time 
value to the failure information and stores the failure infor- 
mation with its time stamp into the system log 117. After the 
system interface 105 receives an event message, it reports 
the occurrence of the event to the CPU 101. 

As another example, the controller 111 may monitor a 
system temperature parameter. For example, a temperature 
sensor (not shown) may be coupled to the CPU 101 for 
monitoring its operating temperature. In one embodiment, 
the temperature sensor generates a voltage which is propor- 
tional to a measured operating temperature of the CPU 101. 
This voltage may then be converted by well-known means 
into a digital data signal and subsequently transmitted to the 
controller 109. The controller 111 then determines whether 
the measured temperature falls within specified limits. If the 
measured temperature is either too low or too high, a 
temperature failure condition is detected and an event mes- 
sage is transmitted to the system interface 105 which sub- 
sequently reports the event to CPU 101 and an entry is 
written to the system log 117 by the system recorder 115. 

In another embodiment, multiple temperature sensors (not 
shown) are coupled to a temperature bus (not shown). The 
temperature readings of all the sensors on the temperature 
bus are monitored every second and are read by temperature 
transducers connected to the chasis controller 112. These 
sensors are read in address order. The criteria for detecting 
a temperature fault is provided by three temperature limits: 
a shutdown limit, which is initialized to 70° C; and two 
warning limits, which are initialized to 55° C. and -25° C. 
Each sensor is compared to the shutdown limit. If any 
temperature exceeds this limit, the system is powered off. 
However, each sensor is first compared to the warning limit. 
If any temperature exceeds this limit, an over-limit fault is 
created, a temperature LED is set, a temperature event 
message is sent to the system interface 105, and an entry is 
written to the system log 117 by the system recorder 115. 

The chassis controller 112 can monitor the presence of 
power supplies, for example. In one embodiment, power 
supplies may be detected and identified by a signal line 
coupling each power supply to a one-wire serial bus which 
is in tum connected to a serial number chip for identifying 
the serial number of each power supply. In order to detect the 
presence of a power supply, a reset pulse may be sent by 
controller 112 to detect a power supply presence pulse. If 
there is a change in the presence of a power supply, a 
presence bit is updated and a power supply event is sent to 
the system interface 105. The power supply data is then 
written to the system log 117. If a power supply is removed 
from the system, no further action takes place. The length of 
the serial number string for that power supply address is set 
to zero. However, if a power supply is installed, its serial 
number is read by the one- wire protocol and written to the 
system log 117. 
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As shown in FIG. 1, thgwrwr cyci^m 1 Q0 furthem iay The system interface 105 may include a system interface 

i nclude a re mote-interfac e 119 also connected to the syste m processor 201 which receives event and request messages, 

bus 107. Th e_ remote inte rface tip a.|sn revives, evqit processes these messages, and transmits command, status 

messa ges from the various ™?mrnl1p;Hi 1fl9j 111, 11 2 has and response messages to the ISA bus and thereby to the 

been detected. The rc renditio n, has been detect ed. The 5 operating system of the CPU 101. In one embodiment, the 

remote intfrfar.f; 119 is a link fo thji servfr syste m 100 for a system interface processor 201 is a PIC16C65 controller 

r emote user or client. The term "client" is usedjQ-rjfcferJQ-a chip manufactured by Microchip Technology, Inc. which 

softwarejirogram. In one embodiment, t he remote in terface includes an event memory (not shown) organized as a bit 

119 enca psulates messages in a transmissio n ^ pack et to vector, having at least sixteen bits. Each bit in the bit vector 

p rovide error-free communications and link security , litis represents a particular type of event. Writing an event to the 

method establishes a commun Tcation protocol in which d ata system interface processor 201 sets a bit in the bit vector that 

is transmitted to a nd from the remote interface 119 by using represents the event. Upon receiving an event message from 

a se rial commumcation protocol known as "byte stuffing ." In me controller 109 (FIG. 1), for example, the system interface 

this communication method, certain byte values in the data 105 sends an interrupt to the CPU 101 via the ISA bus. Upon 

stream always have a particular meaning. For example, a c receiving the interrupt, the CPU 101 will check the status of 

certain byte value may indicate the sta rt or end of a message . 15 me ^ em to*rtox 105 in order to ascertain that an event 

an internipt^nal L or^ar^o5band.Abyte valuema"y ^ pendmg. Alternatively, the CPU10 may periodically poll 

ffidESTihi^^ the ^ ^ alus of system interface 105 m ^order to ascertain 

t- — -r^ — ^ — ■ whether an event is pending. The CPU 101 may then read 

._*L-tr-r~ : _r iin r -i j- • the bit vector in the system interface processor 201 to 

nfrrrough the remote interface 119, a failure condition may M ^ruin the type of event that occurred and thereafter notify 

be reported to a local system operator or to a remote a S y Stem operator of the event by displaying an event 

operator. As used herein, the term "local" refers to a message on a monitor coupled to the CPU 101. After the 

computer, system, operator or user that is not located in the system operator has been notified of the event, as described 

same room as the hardware of the server system 100 but may above, he or she may then obtain further information about 

be located nearby in a different room of the same building ^ the system failure which generated the event message by 

or a different building of the same campus, for example. The accessing the system log 117. The system interface 105 

term "remote" refers to a computer, system or operator that communicates with the CPU 101 by receiving request 

may be located in another city or state, for example, and is messages from the CPU 101 and sending response messages 

connected to the server system via a modem-to-modem back to the CPU 101. Furthermore, the system interface 105 

connection. The remote operator is typically a client who is 30 can send and receive status and command messages to and 

authorized to access data and information from the server from the CPU 101. For example, a request message may be 

system 100 through a remote computer 125. sent from a system operator enquiring as to whether the 

Coupled to the remote interface 119 is a switch 121 for system interface 105 has received any event messages, or 

switching connectivity to the remote interface 119 between enquiring as to the status of a particular processor, 

a local computer 123 and a remote computer 125. As shown 35 subsystem, operating parameter, etc. A request buffer 203 is 

in FIG. 1, the local computer 123 is connected to the remote coupled to the system interface processor 201 and stores, or 

interface 119 via a local communications line 127. The local queues request data in the order that they are received, 

communications line 127 may be any type of communica- Similarly, a response buffer 205 is coupled to the system 

tion line, e.g., an RS232 line, suitable for transmitting data. interface processor 201 and queues outgoing response data 

The remote computer 125 is connected to the remote inter- 40 in the order that they are received. Collectively the request 

face via a modem-to-modem connection established by a buffer 203 and the response buffer 205 are referred to as the 

client modem 129 coupled to a server modem 131. The message data register (MDR) 207. In one embodiment, the 

client modem 129 is connected to the server modem 131 by MDR 207 is eight bits wide and has a fixed address on the 

a telephone line 133. ISA bus which may be accessed by the server's operating 

The system interface 105, the system bus 107, the con- 45 system via the ISA bus 103 coupled to the,MDR"207. As 

trailers 109, 111, 112 and 113, the system recorder 115, the shown in FIG. 2, the MDR 207 has an I/O address (on the 

system log 117, and the remote interface 119 are part of a ISA bus) of OCCOh. "Reads" to that address access the 

network of controllers and processors which form the failure response buffer 205 while "writes" to that address access the 

reporting system of the invention. In FIG. 1, the failure request buffer 203. 

reporting system can be seen as the blocks surrounded by the 50 The system interface 105 may further include a command 

dashed lines. The failure reporting system monitors the register and a status register which are collectively referred 

status and operational parameters of the various subsystems to as the command status register (CSR) 209 which controls 

of the server system 100 and provides system failure and operations and reports on the status of commands. In one 

error reports to a CPU 101 of the server system 100. Upon embodiment the CSR has an I/O address (on the ISA bus) of 

being notified of a system event, the CPU 101 executes a 55 OCClh and is eight bits wide. Reads to that address access 

software program which allows a system operator to access the status register and writes to that address access the 

further information regarding the system failure condition command register. The operation and functionality of CSR 

and thereafter take appropriate steps to remedy the situation. 209 are described in further detail below. 

Referring to FIG. 2, a block diagram of one embodiment Both synchronous and asynchronous I/O modes are pro- 
of the syst em interface 105 is shown surrounded by dashed 60 vided by the system interface 105. Thus, an interrupt line 
lines. The system^ interface 105 provides the interface 211 is coupled between the system interface processor 201 
between the ISA bus and the I 2 C bus. For example, a system and the ISA bus 103 and provides the ability to request an 
operator can access failure information related to a detected interrupt when asynchronous I/O is complete, or when an 
system failure or send commands to devices or the I 2 C bus event occurs while the interrupt is enabled. As shown in FIG. 
by means of the system interface 105. The operating system 65 2, in one embodiment, the address of the interrupt line 211 
of the CPU 101 may be an operating system (OS), such as is fixed and indicated as IRQ 15 which is an interrupt 
Windows® NT or Netware®, for example. address number used specifically for the ISA bus 103. 
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The MDR 207 and the request and response buffers 203 When using the CSR as a command register, the client 

and 205, respectively, transfer messages between a system writes an 8-bit command to the CSR register. In one 

operator or client and one or more as of the microcontrollers embodiment, the commands are: 

on the f*C bus. The buffers 203 and 205 may utilize the Allocate The first command in a sequence of commands, 

first-in first-out (FIFO) technique. That is, the next message s This command clears both request register 203 and 

processed is the one that has been in the queue the longest response register 205. The allocate command can only be 

time. The buffers 203 and 205 have two functions: (1) they successfully accomplished if the interface 105 is not 

match speeds between the high-speed ISA bus 103 and the presently allocated to another client, 

slower system bus 107 (FIG. 1); and (2) they serve as interim Deallocate: The last command in a sequence of commands. 

• r *i_ *_ c c \u* i- *u . io This command clears the done bit and the interface 

buffers for the transfer of messages — this relieves the system TT ^„ _ . . „_ 

. 4 f . t • j 4 i ■ i tv owner ID fields in the CSR status register, 

interface processor 201 of having to provide this buffer. „ . . . U1 . . ~7 1AC . , 

r t>r Enable Interrupts: This enables the interface 105 to send 

When the MDR 207 is written to via the ISA bus 103, it interrupts to the ISA bus. 

loads a byte into the request buffer 203. When the MDR 207 Disable Interrupts: This command disables the interface 105 

is read from via the ISA bus 203, it unloads a byte from the 15 from sending interrupts to the ISA bus. 

response buffer 205. The system interface processor 201 Message: This command informs the interface 105 that a 

reads and executes the request from the request buffer 203 command to be transmitted over the e 2 C bus has been 

when a message command is received in the CSR 209. A P laced in the re 1 uest buffer 203 

response message is written to the response buffer 205 when Clear Done: This command clears the done bit and the CSR 

the system interface processor 201 completes executing the 20 ^, status regisle il . 

, ~. « 4 v. j j •* Clear Interrupt This command clears the interrupt request bit 

command. The system operator or client can read and write . ^ ^£ status re ister 

message data to and from the buffers 203 and 205 by n .m.- ju uu « j a 

. . . . , , m „ . , J Request: This command should be executed after receiving 

executing read and write instructions to the MDR 207 via the aQ ^ m ordef to ^ off ^ faardware intermpt 

ISAbus. 25 request. 

The CSR 209 has two functions, ™* fir ** 'o i r^T Reset: Tnis command unconditionally clears all bits in the 

comm^ajTan d the second is to report on the status of th e * CSR status register except the "event indication" bit. This 

execution of a command. The ; system interface 105 com - command aborts any currently in progress message opera- 

mands^re-usuaUy^euf^ ^ and clears an ^ interrupt. 

issuii nyjTomm^ a ^^ the CSR status to 30 In one embodiment, the 8bit CSR status register has the 

confirm c ommand ^com pletion^_In,a ddition to syn chronous ... 1 

I/0" WdeTTtie~client can also. requesUan-asynchronous I/O ( error indication) 

n5odeToT ;ach command by setting a "Asyn Req" bit in the bit 6 (interrupt enable) 

command. In this mode, an interrupt is generated and sent to ^ bit 5 (event indication) 

the ISA bus 103, via the interrupt line 211, after execution bit 4 (command done) 

of the command has been completed. bi( 3 ( mterrU pt request) 

The interrupt line 211 may use an ISA IRQ 15 protocol, bit 2-0 (interface owner identification). 

as mentioned above, which is well-known in the art. Turning now to FIG. 3, a detailed description of one 

Alternatively, the interrupt line 211 may utilize a level- 40 embodiment of the circuit of the system interface 105 (FIG. 

triggered protocol. A level-triggered interrupt request is 2) will be provided. Generally speaking, the system interface 

recognized by keeping the message at the same level, or 105 may include system interface processor 201 (in one 

changing the level of a signal, to send an interrupt. In embodiment a PIC16C65 microcontroller manufactured by 

contrast, an edge-triggered interrupt, for example, is recog- Microchip Technologies, Inc is used), request buffer 303 in 

nized by the signal level transition. A client can either enable 45 the form of a FIFO memory chip, response buffer 305, also 

or disable the level-triggered interrupt by sending "Enable in the form of a FIFO memory chip, and address decoder 

Ints" and "Disable Ints" commands. If the interrupt line is 302. The system interface processor 201 is coupled to the 

enabled, the system interface processor sends an interrupt data line 304 and the clock line 306 of the I 2 C bus. The 

signal to the ISA bus 103, either when an asynchronous I/O system interface processor 201 is also coupled to the ISAbus 

is complete or when an event has been detected. so via data lines RD 0-7. That interface to the ISA bus 

j . . ,. . . . * t . . corresponds to CSR 209 in FIG. 2. System interface pro- 

In the embodiment shown m FIG 2, the system interface fc ^ d tQ t ^ ^ ^ 

105 may be a single-threaded interface. That is, only one buff£r 3Q5 yia Unes RBQ fa Rfi7 ^ 3Q8 

client, or system operator, is allowed to access the system Output RC2 of system interface processor 201 is coupled to 

interface 105 at a time Therefore, a program or apphcatioo 55 m ^ JRQ M of ^ ^ bus m 

should allocate the system interface 105 for us use before Request buffer 303 has its output from lines DO-7 coupled 

using it, and then deallocate > the interface 105 1 when its (o ^ ^ bus Re e n ^ 3Q5 ^ [{& ^ ^ 

operation is complete IT* CSR 209 indicates .which chen d ^ ^ j^^^ for data to bc 

or operator is allocated access to the system interface 105 at ^ ^ by ^ fequest buffer303 ^ daU 

a particular time. 6Q (o be scnt to ^ IgA bus ffom ^ rcquest bu£fer 305 Data 

For example, in one embodiment, the last three bits of the is sent, or read from, the request buffer 303 by the system 

CSR register are used to indicate whether a client is using interface processor 201 over the lines indicated at 308 

(has control) of the system interface 105. Thus, the last three discussed above. Similarly, data is sent from the system 

bits identify whether the interface is available or who has interface processor 201 to the response buffer 305 also over 

control of the interface. Whether someone has control of the 65 lines indicated as 308. 

system interface 105 can be determined by simply reading The system interface processor 201, request buffer 303 

the CSR register. and response buffer 305 are read from over the ISA bus or 
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are written to over the ISA bus according to ISA address and 
read/write signals which may include timing and enable 
signals generally indicated as 310. Address decoder 302 
generates a write signal for request buffer 303, a read signal 
for response buffer 305 and both read and write and enable 5 
signals for system interface processor 201 in response to the 
ISA address and read/write signals 310. Specifically, when 
ISA address 0CC0H is present at the address decoder and an 
ISA write signal is present, data is received by (or written to) 
request buffer 303. In response to ISA address 0CC0H and 10 
a read signal, address decoder 302 generates the read signal 
for response buffer 305 which allows data to be read from 
that buffer by the ISA bus. When ISA address 0CC1H is 
present and a read signal is also present, address decoder 302 
sends the enable and read signals to signal interface proces- 15 
sor 201 which enables data to be read at the ports repre- 
sented by lines R0-7 in the system interface processor 201. 
Finally, when ISA address 0CC1H and a write signal are 
present, address decoder 302 generates the write and the 
enable signals for system interface processor 201 which 20 
enables data to be written over the ISA bus to the system 
interface processor 201 at lines RDO-7. 

Turning now to FIGS. 4A and 4B, the process followed in 
one embodiment by a client in connection with transmitting 
a message through the interface 105 to a device on the I 2 C 25 
bus, the message operation, will be described. The flow- 
charts represent the steps which are accomplished in one 
embodiment by software operating within the computer 
system. In one embodiment, the software which accom- 
plishes these steps is in the form of a driver routine operating 30 
in CPU 101 (FIG. 1) that is discussed below with regard to 
FIGS. 7A-C 

Referring first to FIG. 4A, the process begins with step 
404. At step 404, the client reads the CSR status register 209 
(FIG. 2) to determine whether the interface owner ID is 35 
cleared. This indicates whether another client has control of 
the interface 105. If the interface owner ID is not clear, as 
indicated by circle 406, the process stops. If the interface 
owner ID is clear, the process continues to step 408 where 
the client issues the allocate command to attempt to take 40 
control of the interface 105. 

Next, at step 410, the client determines whether its 
allocate command was successful by again reading the CSR 
status register and then determining whether its own iden- 
tification now appears in the interface owner ID portion of 45 
the status register. If that has not occurred, the process 
continues to step 412. If the interface owner ID is not clear, 
indicating that a different client has gained control of the 
interface, the process then ends at step 414. If the interface 
owner ID is clear, the process continues to step 416, wherein so 
the client can either return to step 410 and again read the 
status register to determine if its own ID is present, or it can 
continue on to the timeout process indicated by circle 418 
and which is described below in more detail with reference 
to FIG. 4B. 55 

If at step 410 the allocate command is successful and the 
client's ID is then read from the status register, the process 
continues to step 420. At this step, the client has successfully 
taken control of interface 105. 

As described above, the allocate command, when 60 
successful, clears both the request buffer and the response 
buffer. Therefore, at step 420, the client now writes the 
request message to the request buffer 203. Next, at step 422, 
the client writes the "message" command to the command 
status register. Receipt of the "message" command by the 65 
interface 105 causes the interface to begin processing the 
information in the request buffer 203. Next, at step 424, the 
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client waits for an interrupt issued by the interface 105. The 
interface 105 issues the interrupt once it has received a 
response to the "message" command from the ultimate 
recipient or PC bus. When the interrupt is issued, the client 
then reads the response buffer 205 as indicated at step 426. 

Continuing now to FIG. 4B, the process continues to the 
step represented by box 427 where the client issues the clear 
interrupt request command. As was described above, the 
clear interrupt request command turns off the interrupt 
generated by the interface 105. Next, at step 428, the client 
then reads the command status register to determine whether 
the interrupt request bit has been cleared which indicates 
that the clear interrupt request command has been success- 
ful. If the interrupt request bit in the command status register 
has not been cleared, the process continues to step 430. At 
step 430, the client either proceeds to the timeout process 
represented by circle 432 or returns to repeat step 428. Once 
the interrupt request bit has been cleared, the process con- 
tinues on to step 434. 

At step 434 the client issues the deallocate command in 
order to release control of the interface 105. Next at step 
436, the client reads the command status register to deter- 
mine if the interface owner ID has been cleared which 
indicates that the deallocate command has been successful. 
If the interface owner ID has not been cleared, the process 
continues to step 438 wherein the client either proceeds to 
repeat step 436 or proceeds to the timeout process as 
represented by circle 440. 

If at step 436 the client determines that the interface 
owner ID has been cleared, the process continues is com- 
pleted as indicated at step 442 once. 

Referring to the bottom of FIG. 4B, the timeout process 
referred to above will now be described. At step 444 client 
issues the reset command which clears all the bits in the 
command status register except for the event bit and aborts 
any in progress message operation and clears any current 
interrupts. Next, at step 446, the client goes into a wait state. 
In some embodiments the unit state may be for 500 micro- 
seconds. This wait state provides time for the buffers 203 
and 205 to clear. Finally, the process returns to the start of 
the process 402 in FIG. 4A. 

Turning now to FIGS. 5 A and 5B, the process for one 
embodiment wherein the client monitors the interface for 
events which are reported by the microcontrollers on the I^C 
bus will be described. This process is useful in systems in 
which the devices on the I 2 C bus monitor certain parameters 
of the system such as temperature. The flowcharts represent 
the steps which are accomplished by software operating 
within the computer system. 

First, at decision block 510 in FIG. 5 A, the client reads the 
CSR status register to determine whether the interface owner 
ID is cleared. This indicates whether any client has control 
of the interface 105 at this time. If the interface ID is not 
clear, meaning a client has control of the interface, the 
process is exited. If the interface owner ID is clear, the 
process continues on to step 512. At step 512 the client 
issues the allocate command which clears the request and 
response buffers and writes the client's identification into the 
interface owner ID in the CSR status register. At step 514, 
the client determines whether its allocate command was 
successful by again reading the CSR status register and then 
determining whether its own identification now appears in 
the interface owner ID portion of the status register. If the 
command was not successful, the process continues to the 
step represented by decision block 516. At decision block 
516, if the interface owner ID is not clear, the process stops. 
If it is clear, the process continues to step 518. 
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At step 518 the system can either go into a timeout 
process which is previously the same as that described with 
reference to FIG. 4B or the process can return to step 514. 

Once the client has successfully taken control or owner- 
ship of the interface 105 at step 514, the process continues 
to the step represented by box 521. At this step, the client 
issues the enable interrupts command writing that command 
to the CSR. This command enables the interface 105 to issue 
an interrupt over line ISA IRQ 15. 

Next, at decision block 522, the client reads the CSR 
status register to determine whether the interrupt enable bit 
was successfully set. If the interrupt enable bit was not 
successfully set, the process continues to step 524 wherein 
the client either continues to the timeout process described 
previously or returns to step 522. 

Once the enable bit has been successfully set at step 522, 
the process continues to step 526 where it waits for an 
interrupt to be generated by interface 106. 

When an interrupt is generated on the ISA bus by the 
interface 105 (FIG. 2), the process proceeds to step 528 
wherein the client writes a request message to the request 
buffer. Next, at step 530 the client issues the clear done 
command described above. Recall that this command clears 
the done bit in the CSR status register. The process then 
continues to step 532 as will be described with reference to 
FIG. 5B. 

At step 532, the client reads the CSR status register to 
determine if the done bit was successfully cleared. If it was 
not successfully cleared, the process continues to decision 
block 534 where the client either goes to the timeout process 
described previously or repeats the step represented by 
decision block 532. Once the done bit has been successfully 
cleared, the process continues to step 536. At step 536, the 
client issues the message command which, as described 
above, causes the interface 105 to place the message which 
caused the interrupt onto the response buffer 205 (FIG. 2). 
Once this has been accomplished, the done bit is set by the 
interface 105. 

Next, at decision block 538, the client reads the CSR 
status register to determine whether the done bit has been 
set. If the done bit has not been set, as the process continues 
to step 540, wherein the client either proceeds to the timeout 
process as described above or repeats the step represented by 
decision block 538. 

Once the done bit has been set, the process continues to 
step 542. At step 542 the client reads the message which has 
been written to the response buffer 205 by the interface 105. 
Next, step at 544, the client issues the deallocate command 
which relinquishes control of the interface the details of 
which were described previously. Next, at step 546, the 
client confirms that the interface owner ID was successfully 
cleared by the deallocate command. If the interface owner 
ID in the command status register was not successfully 
cleared, the process proceeds to decision block 548 wherein 
the client either goes to the timeout process or repeats step 
546. Once the ioterface owner ID is successfully cleared, the 
process is completed. 

The process by which the system interface 105 handles 
requests from other microcontrollers on the I 2 C bus 107 and 
clients on the ISA bus 103 (FIG. 2) will now be described. 
The flowcharts in FIGS. 6 A and 6B represent the steps or 
actions which are accomplished in one embodiment by 
firmware or software operating within the interface proces- 
sor 201. 

Beginning with step 604, the system interface 105 deter- 
mines whether the I 2 C bus 107 has timed-out. If the bus has 
timed-out, then the process proceeds to step 606 wherein the 
system interface 105 resets the I 2 C bus 107. 
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If the I^C bus has not timed out, the process continues to 
step 608 wherein the system interface 105 determines 
whether any events have occurred. An event occurs when the 
system interface 105 receives information from another 
microcontroller over the I 2 C bus. If an event has occurred, 
the process continues to step 610 wherein the system inter- 
face 105 sets the CSR register event bit to one. The system 
interface 105 also sends an interrupt to the ISA bus if the 
interrupt is enabled. 

The process continues to step 612 from step 610 or 
proceeds directly to step 612 from step 608 if no event has 
occurred. At step 612 the system interface 105 check to see 
if a command has been received in the CSR register 209 
(FIG. 2). If the system interface 105 does not find a 
command, then the process returns to start 602. Otherwise, 
if the system interface finds a command, then the system 
interface starts to parse the command and as represented by 
steps 616-628. 

Lf the "allocate" command is present, the process contin- 
ues to step 616 wherein the system interface 105 resets 
(clears) the response and request buffers 203, 205 and resets 
the done bit in the CSR. The system interface also sets the 
CSR Interface Owner ID. The Owner ID bits identify which 
client has control of the system interface 105. The process 
then returns to start 602. 

If the "de-allocate" command is present at step 612, the 
process continues to step 618 wherein the system interface 
105 clears the response and request buffers 203, 205, resets 
the done bit in the CSR and clears the Owner ID bits. The 
process then returns to start 602. 

If the "clear done bit" command is present at step 612, the 
process continues to step 620 wherein the system interface 
105 clears the done bit in the CSR. The process then returns 
to start 602. 

Referring now to FIG. 7B, if the "enable interrupt com- 
mand" is present at step 612, the process continues to step 
622. At step 622 the system interface 105 sets the interrupt 
enable bit in the CSR. The process then returns to start 602. 

If the "disable interrupt" command is present at step 612, 
the process continues to step 624, wherein the system 
interface 105 clears the interrupt enable bit in the CSR. The 
process then returns to start 602 (FIG. 6A). 

If the "clear interrupt request" command is present at step 
612, the process continues to step 626, wherein, the system 
interface 105 clears the interrupt request bit in the CSR. The 
process then returns to start 602 (FIG. 6A). 

If the "message" command is present at step 612, the 
process continues to step 628. At step 628, in response to the 
message command, the system interface 105 reads data from 
the request buffer 203 (FIG. 2). The first data read from the 
request buffer by the interface I 2 C is the ID (address) of the 
microcontroller for which the message in the request buffer 
is intended. Next, at step 630 the interface determines 
whether the ID is its own. If it is, the process continues to 
step 632 wherein the interface itself responds to the message 
and then returns to start 602 in FIG. 6 A. 

If it is determined at step 630 that the ID is not that of the 
interface, the process continues to step 634 wherein the 
message is sent over the I 2 C bus to the appropriated device. 
The process then returns to start 602 in FIG. 6A. 

Referring now to FIGS. 7A-C, an interface driver will be 
described, which in one embodiment operates in CPU 101 
(FIG. 1) to permit other software programs (clients) to 
access the interface 105. The driver has three aspects: 
message queuing (FIG. 7A), interrupt processing (FIG. 7B), 
and message processing (FIG. 7C). Each of these aspects 
will be described with reference to the figures. 
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Referring first to FIG. 7A, the message queuing process "message queued". If it does, the process proceeds to step 

will be described. The message queuing process is initiated 734 wherein the driver writes the allocated command to the 

by a call from a client as indicated at step 701. The message CSR 209 to obtain allocation of the interface 105. Next, at 

queuing process then begins at step 702, wherein the driver step 736 the queued message is written to request buffer 203. 

attempts to acquire the message queue semaphore. The 5 Then, at step 738 the driver writes the message command to 

message queue semaphore is used to avoid multiple simul- me CSR 209 Next > at 740 me ^ changes the 

taneous accesses to the message queue. Once the message message status to "result awaited". The process then returns 

queue semaphore has been acquired, the process continues to r s j e P 

to step 704 wherein the driver inserts the message from the fc U a J 732 the driver determines the message does not 

r . . . j , r. a ^ n have status queued associated with it, then the process 

^?°to™^^^ a ^'%*^ a »* ta 10 proceeds to step 742. At step 742 the driver determines 

indicate that a message has been queued. The chent can a ^ ^ h J ^ b ^ 

ttinsmit to the driver the actual message, or merely a pomter ^ fl ^ ^ m Note mat me status 

to a buffer containing the message. The message may fl . J ^ ^ processing described previously 

include a pointer to a memory location where a response .f. - J 4 . F ^„ JC , * 

r , ... vt * * * *t\* iL with reference to step 714 in FIG. 7B. If a message has not 

message can be written. Next, at step 706, the message is . , r , , lf . 

r -i j mi ■ * j amved, the process returns to step 730. If a message has 

semaphore is released. This process is repeated every time a ■ j *l .* * * iaa u • .u 

; tl ., , . r r ' arrived the process continues to step 744 wherein the 

client call the driver to queue a message. , . r , . , / 

„ _ ™„ 4„ . . . j . c message being processed is removed from the queue. 

Turning next to FIG. 7B, the processing by the driver of M& J> . . nr c - , roc 

. ° . j . * . J- 1A -°..; L , ... Next, at step 746 the length or size ot the response 

interrupts generated by the interface 105 will be described. * 1 • j . * JT w j- . *u « * *, 

^ . . . . . * « A . - . received is determined. In one embodiment, the first two 

The process begins after an interrupt has been transmitted to 20 . u c . . . ™ . . 

iL ro* L • ,« . . - in / ri . . bytes of the response mdicate its length. Then, at step 748 

the ISA bus by the mterface 105. Starting at step 710 the t , 1 , . -u i- * u « ♦ a £ * . 

, „ J ^„ . . „~ rt , _ ' r-x » » , . . the driver venfies that the client has allocated sufficient 

driver reads the CSR register 209 (see FIG. 2). Next, at step . . T , «. . . , . , 

„* lL , . . , lL v *i_ «j L i « • iL space to receive the response. If sufficient space has not been 

712, the driver determines whether the done bit in the . , r , . . u 

* ... 4 ^, . -j r, A - j L * r allocated, the process proceeds to step 758 wherein the 

status register is set. This provides a first indication of , . n *i_ r * • *• tL * 

. . 5. . . j. . 4 dnver calls the chent with a message indicating that an 

whether the interrupt indicates that a response to a message 25. rc-.ufr n j f . Tu. ° A *u 

. , . e ... A i . 4 . j . insufficient buffer was allocated for the response and the 

has arrived at the interface or whether the interrupt indicates .. , . ... , , , * r 

, , . , ir . , process continues to step 754 described below, 

that an event has occurred. If the done bit is set, the process « • * u i_ « * j »u 

iL . 4 _^ . 4 fm-t m «l j If sufiicient space has been allocated, the process contin- 

then continues to step 714. At step 714, the dnver, in t . _. A r , . . !, r 

. . ; , 4 . . „ .l . *. a ues to step 750 wherein the response in the response register 

response to the done bit being set, changes the status flag * rt< - - ^ 4 i *• n * ju *u i- t 

. , . , iL . «. * * l 205 is wntten to the memory location allocated by the chent 

associated with the message to indicate that a message has 30 c t , XT t * * • 

, _ r u - a • j , - lf ? , for the response. Next, at 752, the message status is set to 

arrived. The use of this flag is described more fully below ™„ r , , , . 4l _ r.. , 

... t-i^ r£ . • CSR command successful, indicating that the message has 

with reference to FIG. 7C. The processing then continues on successfully been read 

to step 716. . • , 4 Next, at step 754 the driver calls the message back routine 

If at step 712 it is determined that the done bit is not set, . . j . T v . ,. . . e tU . . u , 4U 

y , rm-m jk j j j • it i * selected by the chent which informs the client that the 

the process bypasses step 714 and proceeds directly to step 35 . < t « . , ™ . . --^ 

* -\V . * . . , . r , iL iL ' iL r response has been successfully received. Then, at step 756 

716. At step 716, the dnver determines whether the event bit j • -a n . ( l • ♦ r j „ ♦ ♦ <rm« 

p *. . ... , the driver deallocates the mterface and returns to step 730 to 

in the status reg^ter B set. If the event bit is not set the pr0C essing the next message in the queue, 

interrupt processing is complete. However, if the event bit is ^ ^ ^ shown ^ described ^ , 

set, ndicaung that an event has occurred, the process tQ ^ 6mbodimcnls Howev ^ be understood 

contmues to step 718. At step 718 the driver schedules a 40 , * , M1 , . w , . . . , 

/ r« . -„ , by those skilled in the art that vanous changes may be made 

process to read event information. That process will be ' ... . , c . . c 4 . 

^ i. j ■ £. _ L i 4 . i ... c r . « i i therem without departing from the spirit and scope or the 

descnbed in further detail below with reference to blocks r *i_ • *• • • j- * j u *u 

v, . . * - . , . . A mvention. The scope of the mvention is indicated by the 

722-726. Next, at step 720 the driver disables the event , , . . *. , c , . 

.. .. . . 4 t . appended claims rather than by the foregoing descnption. 

interrupt by wnting the disable interrupts command to the A „ , ... ... . J • , r 

rU, -^^ .t i • t .i . . All changes which come within the meaning and range or 

CSR. Then, at step 721 the driver clears the interrupt by 45 . , b P . . . . , * A .... • 

. . 4 , i_^ni--i_i equivalency of the claims are to be embraced within their 

writing the clear interrupt command to the CSR which clears n J 

the interrupt request bit in the CSR status register. SC< What is claimed is* 

As noted above, at step 718, the driver initiates the - A - c ' „. . c c . r 

..... ' . F '-^ „. . . 1. A method of controlhng the transfer of information 

process which includes steps 722-726. Starting at step 722, . . ° c t . , 

f' " . .... F j . . , . f • |_ . between one or more processors on a first bus and one or 

the dnver initiates a process or thread which is treated by the 50 JL , L L • * _r i_ * 

y « ., , . ... 7 C more processors on a second bus through an mterface having 

message insertion process, described previously with refer- _ • . ™™™„nr. 

. t^t/^ - a * i* * a 4 * mi *u an mterface processor, compnsmg: 

ence to FIG. 7A, as a separate chent. At step 724 the process . ; ..... r j .u - . * 

writes a message to the message queue. The particular ™S "^matfn to be transferred across the interface 

message may include a query to the devices on the I 2 C bus kom a ^cond processor on the second bus to a first 

to report back the status of any events. Then, at step 725 the 55 P rocessor on the bus 10 a rec J uest buffer; 

driver may notify clients that have registered for notification a command from the second processor via the 

of the particular event. Such a registry may be maintained by bus to me mterface processor to transfer the 

the driver or by another program. Next, at step 726 the information residing in the request buffer to the first 

process re-enables the event interrupts by writing the enable processor via the first bus; 

interrupts command to the CSR. That completes the process. 60 writing information to be transferred across the interface 

Referring to FIG. 7C, the process by which the driver ^om the first processor on the first bus to the second 

processes messages in the message queue will be described. processor on the second bus to a response buffer; and 

First, at step 730, the driver gets the first message in the reading the information in the response buffer via the 

queue. If no messages are in the queue, the driver waits until second bus. 

a message is queued. Once the driver has obtained the first 65 2. The method of claim 1, further including: 

message in the queue, it proceeds to step 732. At step 732, generating an interrupt on the second bus in response to 

the driver determines whether the status of the message is a request from the first processor on the first bus; and 
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in response to the interrupt, reading the information in the 
response buffer. 

3. The method of claim 1, further including: 
reviewing a status register associated with the interface to 

determine whether the interface is currently allocated; 
if the interface is not currendy allocated, then allocating 
control of the interface to a single client on the second 
bus. 

4. The method of claim 2, wherein the information written 
to the request buffer includes a command to a processor on 
the first bus and wherein the information written to the 
response buffer is transmitted in response to the command. 

5. The method of claim 3, further including: 

setting the status register to indicate that a processor on 
the first bus has reported an event and generating an 
interrupt on the second bus. 

6. A method of transferring information between first and 
second electronic buses through an interface having an 
interface processor, comprising: 

reviewing a status register associated with the interface to 
determine whether a transfer between the buses is in 
process; 

if a transfer between the buses is not in process, then 
writing information to be transferred across the inter- 
face from the second bus to the first bus to a request 
buffer; 

writing a command to the interface processor to transfer 
the information residing in the request buffer to the first 
bus; 

writing information to be transferred across the interface 
from the first bus to the second bus to a response buffer; 
and 

generating a message on the second bus indicating that 
information has been written in the response buffer. 

7. The method of claim 6, wherein the message generated 
is an interrupt on the second bus generated in response to a 
request from a device on the first bus and in response to the 
interrupt, the information in the response buffer is read from 
the second bus. 

8. The method of claim 6, wherein the information written 
to the request buffer includes a command to a device on the 
first bus and wherein the information written to the response 
buffer is transmitted in response to the command. 

9. The method of claim 6, further including: 

setting the status register to indicate that a device on the 
first , bus has reported an event and generating an 
interrupt on the second bus. 

10. A method of controlling the transfer of information 
between a first bus and a plurality of clients on a second bus 
through an interface having an interface processor, compris- 
ing: 

reviewing a status register associated with the interface to 

determine whether the interface is currently allocated to 

one of said plurality of clients; 
if the interface is not currently allocated to a client, then 

allocating control of the interface to a single client on 

the second bus; 
writing information to be transferred across the interface 

from the second bus to the first bus to a request buffer; 
writing a command to the interface processor to transfer 

the information residing in the request buffer to the first 

bus; 

writing information to be transferred across the interface 
from the first bus to the second bus to a response buffer; 

generating an interrupt on the second bus in response to 
a request from a device on the first bus; and 
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in response to the interrupt, reading the information in the 
response buffer from the second bus. 

11. A method of controlling the transfer of information 
between a first bus and clients on a second bus through an 
interface including an interface processor, comprising: 

placing client messages to be transferred across the inter- 
face into a queue; 

reviewing a status register associated with the interface to 
determine whether the interface is currently allocated to 
a client; 

if the interface is not currently allocated to a client, then 

assuming control of the interface; 
writing a first of the client messages in the queue to a 

request buffer, 
writing a command to the interface processor to transfer 

the message in the request buffer to the first bus; 
determining whether a message result has arrived in a 

response buffer in response to a client message that was 

transferred to the first bus; 
determining the size of the response in the response 

buffer; 

verifying that the client associated with the response in 
the response buffer has allocated sufficient space to 
receive the response; and 

writing the contents of the response buffer to a memory 
location allocated by the client. 

12. The method of claim 11, further including repeating 
the method for each message placed in the queue. 

13. The method of claim 11, further including deallocat- 
ing the interface. 

14. A program storage device storing instructions that 
when executed by a computer perform the method compris- 
ing: 

writing information to be transferred across a bus inter- 
face having an interface processor from a second 
processor on a second bus to a first processor on a first 
bus to a request buffer; 

writing a command from the second processor via the 
second bus to the bus interface to transfer the informa- 
tion residing in the request buffer to the first processor 
via the first bus; 

writing information to be transferred across the bus inter- 
face from the first processor on the first bus to the 
second processor on the second bus to a response 
buffer; and 

reading the information in the response buffer via the 
second bus. 

15. A program storage device storing instructions that 
when executed by a computer perform the method compris- 
ing: 

reviewing a status register associated with a bus interface 
between first and second buses to determine whether 
the bits interface is currently allocated to one of a 
plurality of clients; 

if the bus interface is not currently allocated to a client, 
then allocating control of the bus interface to a single 
client on the second bus; 

writing information to be transferred across the bus inter- 
face from the second bus to the first bus to a request 
buffer; 

writing a command to a bus interface processor to transfer 
the information residing in the request buffer to the first 
bus; 

receiving an interrupt on the second bus; 
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in response to the interrupt, reading information in a 

response buffer associated with the bus. 
16. A method of transferring information between an I 2 C 
bus and an ISA bus through an interface, comprising: 
reviewing a status register associated with the interface to 

determine whether the interface is currently allocated; 
if the interface is not currently allocated, then allocating 

control of the i at erf ace to a client on the ISA bus; 
writing information to be transferred across the interface 

from the ISA bus to the I 2 C bus to a request buffer; 



20 



writing a command to an interface processor to transfer 
the information residing in the request buffer to the I^C 
bus; 

writing information to be transferred across the interface 
from the I 2 C bus to the ISA bus to a response buffer; 

generating an interrupt on the ISA bus in response to a 
request from a device on the I 2 C bus; and 

reading the information in the response buffer via the ISA 
bus. 
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